For context, the solution that @coolreader18 and I discussed was to allow you to specify on the reducer, the table you wanted to schedule to. The one detail is that we would need to enforce (at least for now), that at most (and perhaps exactly) one reducer was subscribed to a schedule table. The reason being is that the calling order would not be well defined, and we didn't want people to rely on whatever order we end up calling them in. So that would look like this:

const scheduledMessages = table({public: true}, {
    scheduledId: t.u64().primaryKey().autoInc(),
    scheduledAt: t.scheduleAt(),
    text: t.string(),
 });
 
 const spacetimedb = schema({ scheduledMessages });
 
 spacetime.reducer({ on_schedule = spacetimedb.scheduledMessages });
 // or something similar

The idea was that it would align with the future reactive reducers envisioned in: https://github.com/clockworklabs/SpacetimeDBPrivate/pull/2862

This change would also be an additive change.

Also please add any new syntax we go with to the module-test-ts module. I'm really trying to make sure those are exhaustive.

For context, the solution that @coolreader18 and I discussed was to allow you to specify on the reducer, the table you wanted to schedule to. The one detail is that we would need to enforce (at least for now), that at most (and perhaps exactly) one reducer was subscribed to a schedule table. The reason being is that the calling order would not be well defined, and we didn't want people to rely on whatever order we end up calling them in. So that would look like this:

const scheduledMessages = table({public: true}, {
    scheduledId: t.u64().primaryKey().autoInc(),
    scheduledAt: t.scheduleAt(),
    text: t.string(),
 });
 
 const spacetimedb = schema({ scheduledMessages });
 
 spacetime.reducer({ on_schedule = spacetimedb.scheduledMessages });
 // or something similar

The idea was that it would align with the future reactive reducers envisioned in: clockworklabs/SpacetimeDBPrivate#2862

This change would also be an additive change.

Also please add any new syntax we go with to the module-test-ts module. I'm really trying to make sure those are exhaustive.

I've completely refactored the PR to move in this direction as .schedule() is definitely the wrong direction and is removed from this branch. I have supported both .reducer() and .procedure() though procedures were not called out.

I did go with onSchedule rather than on_schedule to match the rest of TypeScript but as this is a bit of a departure and you think we should go with on_schedule I'll fix that up.

onSchedule is actually the correct capitalization.